I'm digging into this. It feels like we need to define what happens when various algorithms are cancelled halfway through. Eg, what happens if a service worker is killed half way through install, fetch, etc.

I agree that we need to define what happens to in-flight tasks. However, for the purpose of a killswitch, it would be nice if that definition was centralized/global, rather than relying on the individual design of each algorithm. Is it possible to just drop every task on the floor, have fetches fallback to network, nuke a top level state container, and let GC do its thing?

TODO:

• Either specify a time limit for pending promises, or update wait until language to allow killing pending promises without a grace period
• Close any notifications associated with service workers
• Terminate any running background fetches

We'd also need to do something about ongoing background fetches.

This is why I think we need to spec this a little more explicitly rather than try and hand-wave it.

However, these aren't problems created by Clear Site Data. We just haven't been clear about how registrations are cleaned up so far.

Makes sense. I've added the background fetches to the TODO.

I'm hoping we can apply the fetch group concept and do something similar for service workers.